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Abstract. Most of contemporary software systems are implemented using an 
object-oriented approach. Modeling phases - during which software engineers 
analyze requirements to the future system using some modeling language - are 
an important part of the development process, since modeling errors are often 
hard to recognize and correct. 

In this paper we present a framework which allows the integration of Answer Set 
Programming into the object-oriented software development process. OOASP 
supports reasoning about object-oriented software models and their instantia¬ 
tions. Preliminary results of the OOASP application in CSL Studio, which is a 
Siemens internal modeling environment for product configurators, show that it 
can be used as a lightweight approach to verify, create and transform instantia¬ 
tions of object models at runtime and to support the software development process 
during design and testing. 

Keywords: object-oriented modeling, answer set programming, product config¬ 
uration, software systems 


1 Introduction 

Object-oriented programming languages is de facto a standard approach to software 
development. Many systems are modeled and implemented using it. In practice of 
Siemens the object-oriented approach is also used in many domains among which de¬ 
velopment of product configurators is one of the prominent examples. A configurator is 
a software system that enables design of complex technical systems or services based on 
a predefined set of components. In modern configuration systems domain knowledge - 
comprising configuration requirements (product variability) and customer requirements 
- is expressed in terms of component types and relations between them. Each type is 
characterized by a set of attributes which specify functional and technical properties of 
real-world and abstract components of a configurable product. An attribute takes val¬ 
ues from a predefined domain. Furthermore, components are related/connected to each 
other in various ways. 

* This research was funded by the Austrian Research Promotion Agency (grant number 840242) 
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Development of object-oriented configurators is a challenging task due to several 
important issues such as acquisition of configuration knowledge from domain experts, 
modeling of this knowledge, model verification and maintenance. Different types of 
errors might occur, for example, due to the complexity of configuration models or pro¬ 
cedural approach of object-oriented languages. Moreover, a variety of problems arises 
when configurable products or services have a long life-span and requirements are not 
stable, but change over time - for instance, if some components of a product are not 
produced any more or if a new functionality has to be added to a system. Some typical 
challenges occurring when a configuration is changed are discussed in 0. Configura¬ 
tion technologies which address these tasks enable efficient production processes and 
thus can help reduce the overall production costs. 

Logic programming frameworks, such as Answer Set Programming (ASP), can im¬ 
prove the speed and quality of object-oriented development. These frameworks pro¬ 
vide expressive and easily understandable knowledge representation language allow¬ 
ing declarative encodings of complex problems. Equipped with powerful solving algo¬ 
rithms the logic programming frameworks showed their applicability in both product 
configuration as well as software development domains. For instance, important practi¬ 
cal and theoretical aspects of formalizing real-world (re)configuration scenarios using 
a logic-based formalism are discussed in [8l. The authors of JJ] show how to support 
testing object-oriented and constraint-based configurators by automatically generating 
positive and negative test cases using ASP. A commercial ASP-based software for veri¬ 
fication which makes the development of software easier and faster is suggested in iflTll . 

In this paper we present an OOASP framework that uses a generic object-oriented 
configurator to encode its knowledge base and ASP for the computation of configura¬ 
tions. OOASP was implemented as an evaluation prototype for an extension to CSL 
Studio, an authoring environment for Configuration Specification Language (CSL) |[3l. 
It aims at the improvement of the software development process during design and 
testing. We illustrate the mapping from an object-oriented formalism (UML) to logical 
descriptions using a simplified real-world example from Siemens. Additionally, the pa¬ 
per provides different insights on (re)configuration tasks such as validation, completion 
and reconciliation of a configuration which can be accomplished by our system. 

The remainder of this paper is organized as follows. After a short ASP overview in 
Section]^ we describe in Sectionj^how object-oriented knowledge bases can be spec¬ 
ified using ASP within OOASP framework. In Sectionj^we introduce CSL Studio and 
discuss various product (re)configuration scenarios. Finally, in Section]^ we conclude 
and discuss the future work. 


2 Preliminaries 

Answer set programming (ASP) is an approach to declarative problem solving which 
has its roots in logic programming and deductive databases. It is a decidable fragment 
of first-order logic interpreted under stable model semantics an and extended with 
default negation, aggregation, and optimization ifTSll . ASP allows modeling of a variety 
of (combinatorial) search and optimization problems in a declarative way using model- 
based problem specification methodology (see e.g. mi for details). 


An ASP program 7T is a finite set of normal rules of the form: 

6]^,..., 6^, not ,..., not hji, (1) 

where ’not’ denotes default negation, bi (0 < i) and h are atoms. An atom is an expres¬ 
sion of the form p{t), where p is a predicate and f is a vector of terms, i.e. constants, 
variables or uninterpreted function symbols 0. Extensions of ASP lEl allow specific 
forms of atoms. Thus, a cardinality constraint is an atom of the form l{hi ,..., hk}u, 
where /ii,..., are atoms and Z, u are non-negative integers. A literal is either an atom 
a or its negation not a. In rule Q the set of atoms H (r) = {/i} is called head, whereas 
the sets B{r)'^ = {bi,..., bm} and B(r)~ = {bm+i, ■ ■ ■, bn} are positive body and 
negative body, respectively. A fact is a rule r with B{r)~^ U B{r)~ = 0; an integrity 
constraint is a rule r with H{r) = 0; and a choice rule has a cardinality constraint 
as the head h. A literal, rule or program is ground, if it is variable-free. A non-ground 
program 7T can be grounded by substituting variables with constants appearing in 7T. 

Semantics of a ground normal program 7T is defined in terms of Gelfond-Lifschitz 
reduct. Let A{n) be a set of atoms appearing in 77, then 7 C A{n) is an interpreta¬ 
tion. A Gelfond-Lifschitz reduct HD of a program 77 wrt. an interpretation 7 is defined 
as 77^ = {77(r) ^ 77+(r) | r G 77,7 n B~ (r) = 0}. An interpretation 7 is an answer 
set of 77, if 7 is a minimal model of 77^. The semantics of a ground program 77 with 
cardinality contraint atoms is defined similarly, since each rule with such atoms can be 
translated into a set of normal rules na. Informally, semantics of a cardinality con¬ 
straint requires at least I and at most u atoms hi to be in an answer set. 

Moreover, ASP allows finding of preferred answer sets. The preferences are defined 
by weak constraints - a specific type of integrity constraints that can be violated. Each 
violation is penalized by a weight associated with a constraint. Given a program with 
weak constraints an ASP solver returns an answer set minimizing the sum of penalties. 

3 OOASP framework 

The development of an object-oriented software is a complex and error-prone activity 
that requires careful modeling of an underlying problem. Siemens experience in the de¬ 
velopment of industrial applications shows that quite often incorrect models are respon¬ 
sible for faults in software artifacts that are hard to identify and debug. In this section we 
present the OOASP approach which allows to analyze object-oriented software mod¬ 
els and their instances by means of ASP. In particular, we consider those models that 
can be described by a modeling language corresponding to a UML class diagram ifTSll . 
The latter is a language allowing a software developer to specify an object model and 
additional constraints that each valid instantiation of an object model must satisfy. 

In order to reason about a software model, OOASP framework uses a meta-program¬ 
ming approach uni which was successfully applied in a similar way, for instance, to 
debugging of ASP programs 1101121 . In our meta-programming approach an ASP pro¬ 
gram over a meta-language manipulates an ASP program describing a software model 
in terms of the Domain Description Language (DDL). In case of OOASP, all concepts 
of one or multiple software models as well as their instantiations are represented in 
OOASP-DDL as a set of rules of the form 0. Then, a meta-program, designed to 




accomplish a specific reasoning task, is applied to a program in OOASP-DDL. In a 
standard implementation of OOASP we provide meta-programs accomplishing the fol¬ 
lowing task^ 

Validation Given an OOASP-DDL program describing an object-oriented model and 
its instantiation, a validation meta-program verifies whether all integrity and domain- 
specific constraints hold. The integrity constraints encode model requirements to 
relations between objects of an instantiation and are derived from the given model 
automatically. The domain-specific constraints ensure that some specific require¬ 
ments to an instantiation of a model are satisfied. They can either be directly speci¬ 
fied in the meta-program or imported from other languages. For instance, one could 
import domain-specific constraints defined in Object Constraint Languag^(OCL), 
for which transformations to SAT m and constraints programming m exist. 
Completion Given an OOASP-DDL program describing an object-oriented model and 
its (partial) instantiation, the completion task is to find an extension of the instanti¬ 
ation that satisfies all constraints or to show that such extension does not exist. The 
latter may occur due to two main reasons: (i) the object-oriented model or the given 
(partial) instantiation are inconsistent and do not have a completion - an empty in¬ 
stantiation can be seen as a special case for the completion; and (ii) the extension 
of the given instantiation requires the creation of a number of objects that exceeds 
the given upper bounds for object instances. 

Reconciliation Given an OOASP-DDL program describing a legacy instantiation of an 
outdated object-oriented model, a new up-to-date model and a set of transformation 
rules, the goal of the reconciliation is to find a possibly preferred set of changes 
required to transform the legacy instantiation to a valid instantiation of the new 
model. The preferences in OOASP can be defined with domain-specific costs that 
assess the costs of required changes such as creation, reuse or disposal (deletion) 
of object instances. 

If advanced features such as multiple inheritance, symmetry breaking, etc., are required, 
the default ASP encodings of reasoning tasks, outlined in this paper, must be replaced 
with alternative encodings, whereas the OOASP-DDL program remains the same. 

3.1 OOASP Domain Description Language 

OOASP-DDL allows a software developer to define all standard concepts of object- 
oriented models such as classes, attributes and associations. Each concept of the model 
is translated to a corresponding OOASP-DDL atom, where each term /d* is an identifier 
of a model, class, attribute, etc. In OOASP identifiers of models are globally unique, 
whereas all other identifiers are unique within a model. In the current version OOASP- 
DDL supports the definitions presented in Table These definitions are sufficient to 
describe a subset of the object-oriented model of programming languages such as C-H-, 
Java, etc. Many features that can additionally be found in object-oriented models, e.g. 
initial values, constants, multi-valued attributes, ordered associations, etc., are currently 

' OOASP code and encodings are available upon request from the first author. 

^ OCL specification is available from http://www.omg.Org/spec/OCL/2.4/PDF/ 



ooasp-class{ldM, Idc) 
ooasp-Subclass{IdM, Idc, Idsc) 

ooasp.assoc{IdM, Id a, Idci , Minci , 
Maxci , Id- C2, Minc2 , Maxc2 ) 


ooaspMttribute{Id M , Idc, Uat, 

{ “string”, “integer”, “boolean”}) 
ooasp.attributejninlnclusive^IdM, 
Idc, Uat, MinV) 

ooasp.attributejnaxInclusive^IdM, 
Idc, Uat, MaxV) 
ooasp-attribute-enum{U M, 

Idc, Uat, Val) 

Table 1. OOASP-DDL 


a class C is defined in a model M 
defines a subclass relation between a class C and a su¬ 
per class CS in a model M 

defines an association relation A between classes Ci 
and C 2 with the given cardinalities, e.g. for every in¬ 
stance of the class Ci at least Minc 2 and at most 
Maxc 2 instances of the class C 2 must be associated 
an attribute AT of & class C is defined to have one of 
the three possible types 

provides an optional minimum value Min V for an in¬ 
teger attribute AT 

provides an optional maximum MaxV for an integer 
attribute AT 

defines a possible value Val for a string attribute AT 
definitions for the encoding of models 


ooaspjinstantiation{UM, Uj) 
ooaspJsa{Ui, Idc, Uq) 
ooasp-asaociated{U I, Id a, 

Ido ,, Woa) 

ooasp-attribute-Value{Ui, Uat, 
Ido, Val) 


defines an instantiation / of a model M 
declares that an object O is an instance of the class C 
objects Oi and O 2 are associated by the association re¬ 
lation A 

assigns a value Val to an attribute AT of an object O 


Table 2. OOASP-DDL definitions for the encoding of instantiations 


not supported by the framework. This is because our main purpose was to provide a 
lightweight approach that, however, is able to capture most of the features commonly 
used in practice. The definition of an instantiation of an object-oriented model is done 
using OOASP-DDL in a similar way as the definition of the model. In particular, our 
language allows the definitions shown in Table 

Note that, OOASP-DDL is designed in a way to allow the definition of multiple 
models and their instantiation in one ASP program. This provides the necessary support 
for reconciliation and similar reasoning tasks that are applied to many models and/or 
their instantiations at once. 


3.2 Definition of constraints 

Constraints allow a software developer to ensure that models and their instantiations are 
valid. In OOASP we support two types of constraints: integrity constraints and domain- 
specific constraints. The latter are used to verify some specific properties of a model 
and/or its instantiations. The definition of domain-specific constraints can be done by 
a developer directly in OOASP-DDL or by importing them from the input model, e.g. 
OCL constraints from a UML model. The integrity constraints, however, are included 
in the default OOASP implementation and capture the requirements of the input object- 
oriented model such as cardinality restrictions, typing, etc. For instance, in order to 


ensure that a minimal cardinality requirement of an association relation holds in a given 
instantiation, OOASP framework comprises the following rul^ 

ooasp_cv(I,mincardviolated(01,A)) 

{ooasp_associated(I,A,01,02): ooasp_isa(I,C2,02)} C2MIN-1, C2MIN>0, 
ooasp_assoc(M,A,Cl,CIMIN,CIMAX,C2,C2MIN,C2MAX), 
ooasp_instantiation(M,I), 
ooasp_isa(I,C1,01). 


The presence of an atom over ooasp^cv predicate in an answer set of an OOASP pro¬ 
gram indicates that a corresponding integrity constraint is violated by the given instan¬ 
tiation. In the sample rule above, the error atom is derived whenever less objects of 
type C 2 are associated with object Oi than required by the cardinality restriction of the 
association. 


4 System description 

OOASP was implemented as a potential extension to any object-oriented modeling en¬ 
vironment and its practicability was evaluated together with CSL Studio Q. The latter 
is a Siemens internal tool for the design of product configurators as Generative Con¬ 
straints Satisfaction Problems (GCSPs) 1171 18L CSL (Configuration Specification Lan¬ 
guage) is a formal modeli^ language based on a standard object-oriented meta-model 
similar to Ecor^or MOF[j It provides all state-of-the-art features such as packages, 
interfaces, enumerations, classes with attributes of various types, associations between 
classes, inheritance and aggregation relations. In addition, it offers reasoning methods 
such as rules and constraints which are not covered in this work. The reason is that they 
are not (yet) translated into OOASP domain-specific constraints. 

A screenshot of CSL Studio, presented in Fig. shows an example of a simple 
hardware configuration problem. A configuration problem corresponds to a composi¬ 
tion activity in which a desired configurable product is assembled by relating individ¬ 
ual components of predefined types. The components and relations between them are 
usually subject to constraints expressing their possible combinations allowed by the 
system’s design. The types of the components, relations between them as well as addi¬ 
tional constraints on sets of related components constitute configuration requirements. 
Many of those constraints can be expressed in an object-oriented model as cardinalities 
of association and aggregation relations. 

The sample model shown in Fig. [T] describes a product configuration problem as 
a UML class diagram. In this problem the hardware product consists of a number of 
Frames. Each frame contains up to five Modules of types ModuleA or ModuleB, where 
each module occupies exactly one of the 5 positions in a frame. Moreover, each module 
has exactly one Element assigned to it. All elements are of one of two types ElementA 

^ In our examples we use the gringo (9( dialect of ASP that also allows usage of uninterpreted 
function symbols such as mincardviolated. 

Eclipse Modeling Framework https://www.eclipse.org/modeling/emf/ 

^ MetaObject Facility http://www.omg.org/mof/ 








Fig. 1. CSL screenshot for the Modules example 


or ElementB. The corresponding OOASP-DDL encoding for this example is automati¬ 
cally generated by CSL Studio. A part of the encoding excluding integrity constraints 
is shown in Listing [T] 

Additionally to the integrity constraints, implied by the cardinalities of associations 
shown on the UML diagram, there are the following domain-specific constraints: 

- Elements of type ElementA require a module of type ModuleA 

- Elements of type ElementB require a module of type ModuleB 

- Modules must occupy different positions in a frame 

These constraints can easily be implemented in OOASP. Eor instance, the first and the 
third can be formulated as shown in Listing]^ 

A typical workflow of the product configurator development process in CSL Studio 
and OOASP is depicted in Pig. The development starts with a creation of an initial 
configuration model in CSL. Then, the model can be exported to OOASP and extended 
by the definition of domain-specific constraints. Pinally, the consistency of the devel¬ 
oped model can be verified by execution of different reasoning tasks. Eor instance, the 
existence of model instantiations can be checked by running a completion task with an 
empty instantiation. The validation task can be used to test whether some of the known 
valid product configurations are instantiations of the model. Moreover, OOASP can be 
used during the implementation phase. Thus, CSL Studio allows a software developer to 
export a created model to a preferred object-oriented language as a set of classes. These 
generated classes must then be extended with the implementation of domain-specific 
constraints as well as additional methods and fields required for correct functionality of 
the software. In order to ensure that the software is implemented correctly, the software 
developer can export a (partial) instantiation generated by an object-oriented program to 












































1 y, modules example kb "vl" 

2 Z classes 

3 ooasp_class("vl","HwObject"). 

4 ooasp_class("vl","Frame"). 

5 ooasp_class("vl","Module"). 

6 ooasp_class("vl","ModuleA"). ooasp_class("vl","ModuleB"). 

7 ooasp_class("vl","Element"). 

8 ooasp_class("vl","ElementA"). ooasp_class("vl","Elements"). 

9 % class inheritance 

10 ooasp_subclass("vl" , "Frame" , "HwObject") . 

11 ooasp_subclass("vl" , "Module" , "HwObject") . 

12 ooasp_subclass("vl" , "Element" , "HwObject") . 

13 ooasp_subclass("vl" , "ElementA" , "Element") . 

14 ooasp_subclass("vl" , "Elements" , "Element") . 

15 ooasp_subclass("vl" , "ModuleA" , "Module") . 

16 ooasp_subclass("vl" , "ModuleB" , "Module") . 

17 Z attributes and associations 

18 Z class Frame 

19 ooasp_assoc("vl","Frame_modules","Frame",1,1,"Module",0,5). 

20 Z class Module 

21 ooasp_attribute("vl" , "Module" , "position" , "integer") . 

22 ooasp_attribute_minInclusive("vl","Module","position",1). 

23 ooasp_attribute_maxInclusive("vl" , "Module" , "position" ,5) . 

24 Z class Element 

25 ooasp_assoc("vl","Element_module","Element",1,1,"Module",1,1). 


Listing 1. OOASP-DDL encoding of the Modules example shown in Fig.[^ 


OOASP. In this case the completion reasoning task allows to test whether the obtained 
partial solution can be extended to a complete one, e.g. by creating missing modules for 
the elements as well as by adding missing frames and assigning the modules to them. 
In addition, if the software developer (tester) manipulates a completed configuration, 
for instance, by adding or removing elements, the configurator can restore consistency 
through reconciliation. The latter hnds a set of changes that keep as much of the ex¬ 
isting structure of the conhgured system as possible. In the following subsections we 
describe some use cases exemplifying OOASP applications during the development of 
conhgurators. 

4.1 Validation of a configuration 

The implementation of an object-oriented software requires continuous testing in order 
to identify and resolve faults early. The validation reasoning task provided by OOASP 





ooasp_cv(I,module_element_violated(Ml,E1)) :- 
ooasp_instantiation(M,I), 

ooasp_associated(I,"Element_module",M1,E1), 
ooasp_isa(I,"ElementA",E1), 
not ooasp_isa(I,"ModuleA",M1). 

ooasp_cv(I,alldiffviolated(Ml,M2,F)) :- 
ooasp_instantiation(M,I), 
ooasp_isa(I,"Module",M1), 
ooasp_isa(I,"Module",M2), 
ooasp_attribute_value(I,"position",M1,P), 
ooasp_attribute_value(I,"position",M2,P), 
ooasp_associated(I, "Fraiiie_modules" ,F,M1) , 
ooasp_associated(I, "Fraiiie_modules" ,F,M2) , 

Ml != M2. 


Listing 2. Sample domain-specific constraints in OOASP 


allows a software developer to verify whether an instantiation generated by the object- 
oriented code is consistent. Especially, the validation is important in the context of CSL 
Studio or similar systems while testing domain-specific constraints. Thus, in CSL Stu¬ 
dio an instantiation of the object model provided by the software developer is automat¬ 
ically exported to OOASP and the validation meta-program is executed. The obtained 
answer set is then used to highlight the parts of the instantiation that violate require¬ 
ments to a valid configuration. Using this information, the developer can identify the 
faults in the software in a shorter period of time. 

For instance, assume a software developer implemented a model designed in CSL 
Studio and the resulting program outputs an instantiation c2 comprising only one ele- 


Production system CSL Studio 



Software 

developer 


Add constraints, 
execute reasoning 
tasks 


IDE 


Fig. 2. Integration of OOASP in development of product configurators 


















ment of type ElementA. CSL Studio forwards this instantiation to OOASP which trans¬ 
lates it to the OOASP-DDL program; 

ooasp_isa("c2","ElementA",10). 

For this input, execution of the validation task returns an answer set comprising: 

ooasp_cv( "c2" .mincardviolated(10, "Element Jiiodule" ) ) 

This atom indicates that cardinality restrictions of the association between Element and 
Module classes are violated. The reason is that for the object with identifier 10 there is 
no corresponding object of the Module type. 

Note that in the current OOASP prototype domain-specific constraints must be 
coded by a software developer manually and are not generated from the CSL (con¬ 
straint language). However, this behavior was found to be advantageous in practice, 
since it provides a mechanism for the diverse redundancy 0. The latter refers to the 
engineering principle that suggests application of two or more systems. These systems 
are built using different algorithms, design methodology, etc., to perform the same task. 
The main benefit of the diverse redundancy is that it allows software developers to 
find hidden faults caused by design flaws which are usually hard to detect. Generally, 
we found that software developers are able to formulate domain-specific constraints in 
OOASP after a short training. However, existence of ASP development environments 
supporting debugging and testing of ASP programs would greatly simplify this process. 

4.2 Completion of an instantiation 

The completion task is often applied in situations when a software developer needs to 
generate a test case for a production system that outputs an invalid instantiation. Thus, 
the completion task allows a developer to detect two types of problems: (i) invalid par¬ 
tial instantiation and (ii) incomplete partial instantiation. In the last case, the partial 
instantiation returned by a configurator can be extended to a valid one by adding miss¬ 
ing objects and/or relations between them. This indicates that the already implemented 
production system works correctly, at least for the given input, but it is incomplete. 
The developer can export the obtained solution and use it as a test case during subse¬ 
quent implementation of the system. If the problem of the first type is found, then we 
have to differentiate between two causes of this problem: (a) the model designed in the 
CSL Studio is inconsistent; and (b) the system returned a partial instantiation that is 
faulty, i.e. cannot be extended to a valid solution. The first cause can easily be detected 
by running a completion task with an empty instantiation. If the model is consistent, 
then manually coded additional constraints of the production system are faulty and the 
software developer has to correct them. 

In order to execute the completion task the CSL Studio exports an instantiation ob¬ 
tained by an object-oriented system to OOASP-DDL. Then, this instantiation together 
with a corresponding meta-program is provided to an ASP solver. The returned answer 
sets are visualized by the system to the software developer. If needed, the developer can 
export the found complete instantiation to an instantiation of the object-oriented sys¬ 
tem. This translation is straight-forward due to the one-to-one correspondence between 
instances on the OOASP-level and the object-oriented system. 


Consider an example in which a partially implemented configuration system returns 
an instantiation containing three instances of ElementA and two instances of ElementB. 


% Partial configuration 
ooasp_instaiitiation("vl" , "cl") . 

ooasp_isa("c3","ElementA",10). ooasp_isa("c3","ElementA",11). 
ooasp_isa("c3","ElementA",12). 

ooasp_isa("c3","ElementB",13). ooasp_isa("c3","ElementB",14). 


In this case the completion task returns a solution visualized in Fig. This solution 
comprises the existing objects with identifiers 10 - 14 as well as the new objects coiTe- 
sponding to a frame with object identifier 30 and five modules 20 - 24. 



Fig. 3. Complete instantiation for the Modules example. The objects existing in the input instan¬ 
tiation are shown in gray. 


4.3 Reconciliation of an inconsistent instantiation 

The reconciliation task deals with restoring consistency of an inconsistent (partial) in¬ 
stantiation given as an input. The problem arises in three scenarios: (1) the validation 
task finds an instantiation inconsistent; (2) the completion task detects that a model is 
consistent, but the given partial instantiation cannot be extended; and (3) the model 
is changed due to new requirements to a configurable product. In order to restore the 
consistency of an instantiation the reconciliation task comprises two meta-programs. 
One meta-program converts the input OOASP-DDL program into a reified form. This 
program comprises rules of the form: 

fact{ooasp(t)) :-ooasp{t). 

where ooasp{i) stands for one of the OOASP-DDL atoms listed in Table|^ The second 
meta-program takes the output of the first one as an input and outputs a consistent 
instantiation as well as a set of changes applied to obtain it. The set of changes is 
obtained by the application of deletion/reuse rules of the form: 

\{reuse(ooasp{t)), delete[ooasp{t)Y\ \ :- fact{ooasp{t)). 

ooasp(t)reuse{ooasp{t)). 

























A preferred solution can be found if a developer provides costs for reuse/delete actions 
performed by the reconciliation task. 

For example, suppose that the developer created a configuration system that does not 
implement a domain-specific constraint preventing overheating of the system. Namely, 
this constraint avoids overheating by disallowing putting two modules of type ModuleA 
next to each other. 


y, do not put 2 modules of type ModuleA next to each other 
ooasp_cv(IID.moduleANextToOther(Ml,M2,P1,P2)):- 
ooasp_instantiation("v2",IID), 
ooasp_associated(IID, "Franie_modules" ,F,M1) , 
ooasp_associated(IID,"Frame_modules",F,M2), 
ooasp_attribute_value(IID,"position",M1,P1), 
ooasp_attribute_value(IID,"position",M2,P2), 

Ml!=M2, 

ooasp_isa(IID,"ModuleA",M1), 
ooasp_isa(IID,"ModuleA",M2), 

P2=P1+1. 


Due to the added constraint, the instantiation in Fig.|^is no longer valid. The reconcilia¬ 
tion task hnds a required change by modifying the positions of modules with identifiers 
21 and 24. The result of the reconciliation can be presented to a developer by OOASP 
framework as shown in Fig. 



Fig. 4. Reconciled configuration for the Modules example 


5 Conclusions 

This paper demonstrates OOASP which integrates ASP into the object-oriented soft¬ 
ware development process using an industrial product configurator as an evaluation 
example. Our preliminary results are very encouraging and open a number of new di¬ 
rections for a tighter integration of object-oriented programming and ASP. Thus, our 
experiments with OOASP showed that checking constraints with respect to a given 
object-oriented model can be done efficiently by modern ASP solvers. However, execu¬ 
tion of the reconciliation task still remains a challenge for large-scale instantiations |[8|. 



























It appears that the main obstacle for the approach based on ASP meta-programming 
is the explosion of grounding. In addition, the completion of large-scale instantiations 
indicated that a computation time for a solution can be improved by the application of 
domain-specific heuristics. The latter are often hard to implement for software develop¬ 
ers, since they do not have enough experience in ASP. In our future work we are going 
to investigate these questions in more details. 
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